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This  repox  t  describes  new  progress  in  the  design  of  data  fusion  techni¬ 
ques.  Previous  work  (reference  1 )  resulted  in  the  experimental  modeling  of  an 
automated  system.  Artificial  •* ntelligence  techniques  included  in  the  model 
were  natural  language  process!  (NLP),  rule-based  updating  of  the  system  data¬ 
base,  and  rulebased  irferencing  for  tactical  data  fiision.  Emphasis  in  the 
latest  work  is  on  the  sharing  of  knowledge  by  cooperating  subsystems  of  a  C3 
system  and  the  representation  of  complex  concepts.  Other  issues  addressed  are 
the  subdivision  of  memory  for  different  functions  emd  \iser-assisted  fusion. 

STSTBI  OVERVXEH 

Figure  1  shows  the  component  rulesets  (procedural  )cnowledge)  and  memories 
(descriptive  knowledge)  of  a  rule-based  system  that  caui  perform  automated  and 
user-assisted  fusion  and  support  extensive  qpierying  cap^Uailities.  (The  archi¬ 
tecture  is  shown  primarily  as  a  ROSIE  implementation;  other  systems  would  have 
moderate  variations.)  Examples  of  event  updating,  data  retiring,  and  data 
fusion  appear  in  references  1  and  2. 

Constraining  fusion  rules  to  operate  only  on  a  relatively  small  part  of 
the  datalaase  as  shown  in  figure  1  is  being  investigated  as  a  method  of  increas- 
^*^9  efficiency  in  rule  evaluation.  Most  data  will  not  be  directly  pertinent 
to  the  conditions  of  My  fusion  rules  but  will  be  of  potential  interest  to  the 
user.  A  query-only  memory  would  include  details  of  plMS  and  activities 
(e.g. ,  responsibilities,  crews,  circuits,  buoy  patterns)  and  free-form  com¬ 
ments.  Examples  of  free-form  comments  on  a  report  or  event  are  "identity  of 
Barsuk  and  Kobchik  may  be  reversed"  and  "wreckage  pieces  had  US  markings." 
These  comments  often  would  derive  from  the  residue  of  an  NLP  subsystem. 

Several  widely  different  approaches  may  be  taken  to  restrict  fusion  rule 
evaluaUon  to  the  pertinent  data,  and  which  one  to  follow  is  an  important  con¬ 
sideration  when  designing  a  database  system.  Our  modeling  of  separate  memo¬ 
ries  in  experiments  employs  the  multiple  database  cap^d)i.lity  of  ROSIE  (refex- 
ence  3).  Rulesets  are  organized  according  to  the  memory  they  use  and  feed,  so 
activation  of  a  memory  is  needed  less  frequently. 

The  history  file  contains  the  data  retired  from  the  data  fusion  system 
when  no  longer  pertinent  to  current  situation  assessment.  (The  fusion  system 
user,  however,  should  have  access  to  the  history  file.)  In  addition  to  old 
information,  those  data  include  recently  fulfilled  or  rejected  plans  and  pre¬ 
dictions.  References  1  and  2  discuss  and  illustrate  the  retiring  process. 
The  history  file  can  be  used  later  in  reconstructing  and  analyzing  the  flow  of 
events  of  naval  exercises  and  operations.  Most  data  will  not  originally  be  in 
the  syntax  of  the  rule-based  system,  and  some  in  addition  will  be  in  natural 
language.  Also,  geographical  and  other  spatial  Information  may  be  stored  in 
another  medium,  such  as  video  or  optical  disks,  or  in  an  untranslatable  repre¬ 
sentation.  If  so,  external  evaluation  of  rule  conditions  involving  certain 
spatial  concepts  or  fuzzy  set  mappings  could  be  the  simpler  approach.  In 
figure  1,  the  external  boxes  interfaced  with  represent  the  processes 

needed  to  convert  various  kinds  of  data  into  a  usable  form.  The  rule-based 
system  will  have  the  ability  to  convert  formatted  data  into  its  own  syntax, 
which  is  useful  when  new  sources  of  data  are  tapped,  but,  in  general,  syntax 
conversion  will  be  more  efficiently  performed  before  input. 


1 


\ 


RULE-BASED  SYSTEM  FOR  TACTICAL  DATA  FUSION 


DATABASE  UPDATING 
RULESETS 


EVENT 

UPDATING 


DATA 

RETIRING 


SYNTAX 

CONVERSION 


MAIN  RULESETS 


FUSION  RULESETS 


QUERY  FACILITATING 
RULESETS 


COMPUTATIONAL 
RULESETS  (GEOM., 
CONFIDENCES,  ETC.) 


SYSTEM  FOR 
EVENT 

RECONSTRUCTION 
4  ANALYSIS 


- i - ■ 

_ 1 _ 

DBMS 

PRIVATE 

MEMORY 

MEMORY  FOR 
FUSION  AND 
QUERY 

MEMORY  FOR 
QUERY  ONLY 

HISTORY 

FILE 

EXTERNAL 

CONDITION 

EVALUATION 


EXTERNAL 

SYNTAX 

CONVERSION 


■—  DATAFLOW/ACCESS 
— —  SPECIAL  PROCESSING 
FOR  SPECIAL  DATA 


NATURAL 

LANGUAGE 

PROCESSING 


MEDIUM 

CONVERSION 


MESSAGES  AND 
OFFLINE  OH  REMOTE 
DATABASES 


Figure  1.  Internal  and  external  interactions  of  a  rule-based  data  fusion  system. 
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Figure  1  suggests  Independence  of  NIP  (the  conversion  of  narrative  input 
data  into  system  syntax),  Inferenclng,  and  query  functions.  Much  of  the  same 
knowledge  is  needed  by  these  processes,  as  indicated  in  figure  2,  so  we  are 
Investigating  methods  of  sharing  it.  Several  approaches  to  sharing  reasoning 
processes  among  the  inferenclng  subsystem  and  the  NIP  subsystem  were  outlined 
in  reference  2,  and  much  additional  work  in  that  area  is  needed.  Ihe  sharing 
of  reasoning  processes  by  the  query  sxibsystem  with  other  subsystems  is  also  a 
possibility.  Mechanisms  for  querying  the  database  are  currently  built  into 
most  rule-based  systems,  but  the  queries  must  be  stated  in  highly  constrained 
forms.  A  fully  natural  language  query  capability  would  require  considerable 
linguistic  knowledge.  One  approach  would  be  to  use  em  "off  the  shelf"  trans¬ 
portable  database  interface  (see  references  4  and  5  for  a  description  of  the 
concept)  and  program  it  for  the  tactical  applications.  Since  the  linguistic 
knowledge  needed  for  handling  queries  differs  sone%fhat  frcrni  that  for  convert¬ 
ing  input  data,  the  failure  to  share  linguistic  knowledge  with  the  NIP  svibsys- 
tem  might  not  be  unduly  wasteful.  However,  new  vocabulary  learned  by  one  NLP 
subsystem  would  be  usefully  shared  with  other  NLP  subsystems,  since  the  mes¬ 
sage  creator,  the  "expert"  contributing  fusion  rules,  aru3  the  query  system 
user  will  use  similar  vocabulary. 

REPRESENTATZCm  OF  DESCRIPTIVE  INFORMATION 

Several  )cinds  of  expert  systems  will  be  cooperatively  functioning  in  tac¬ 
tical  reasoning  activities  and  will  require  much  of  the  same  knowledge.  One 
system  not  shown  in  figure  1  is  a  mission  planning  system,  and  a  mission  plan¬ 
ning  system  under  development  (reference  6)  uses  FRL  (frame  representation 
language  (reference  7)).  While  the  procedural  information  of  the  various 
systems  may  be  coded  very  differently,  there  is  a  large  degree  of  commonality 
among  the  forms  in  which  descriptive  information  is  stored.  For  example,  the 
tactical  situation  assessment  system  STAMMER2  (reference  8)  uses  relational 
triples  (i.e.,  2-node  relational  assertions),  most  of  the  descriptive  data  in 
FRL  can  be  easily  converted  to  relational  triples  (frame-slot-datum),  the  high- 
level  programming  l2uiguage  Prolog  includes  the  representation  predicate  (argi , 
arg2),  and  ROSIE's  many  representation  forms  include  the  equivalent  of  rela¬ 
tional  triples.  (For  most  systems,  the  node/value  may  be  a  tuple  or  list  or 
the  equivalent.)  Examples  of  representations  of  translatable  assertions  from 
a  file  of  infrequently  used  data  are  the  following.  (The  relation  "IS  A"  or 
"isa"  is  inferred  in  STAMMER2  when  no  relation  is  given.  Equivalently,  AIO 
represents  "an  instance  of.") 

ROSIE:  PANAMA  is  a  nation. 

PANAMA  CANAL  is  a  part  of  PANAMA. 

GATUN  LAKE  is  a  part  of  PANAMA. 

STAMMER2:  (NATION  PANAMA) 

(PART  PANAMA  PANAMA-CANAL) 

(PART  PANAMA  GATUN-LAKE) 

Prolog:  nation ( panama ) . 

part(panama,  panama-cemal) . 
part(panama,  gatun-lake). 
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WtlLx  (PANAMA  (AlO  ($VALUE  (NATION))) 

(HAiS-PART  ($VALUS  (PANAMA>CANAL)  (GATUN-LAKE) ) ) ) 

(NATION  (INSTANCES  ($ VALUE  (PANAMA)))) 

We  next  consider  representing  in  relational  triples  the  descriptive  data 
shared  ty  the  systems.  The  following  facts  and  educated  conjectures  should 
influence  the  selection  of  the  method  of  representation  of  descriptive  data. 

•  the  NLP  system,  planning  system,  inference  system,  query  system,  his¬ 
tory  system,  etc.,  will  all  use  much  of  the  same  data. 

•  The  users  generally  will  not  have  had  experience  with  expert  systems, 
but  WILL  be  2Uble  to  quicicly  learn  to  read  and  write  in  relational 
triples . 

•  Information  stored  as  relational  triples  is  easily  retrieved. 

e  More  complicated  structures  (e.g.,  ROSIE  assertions  with  verbs,  adjec¬ 
tives  and  prepositions)  can  be  used  to  represent  procedural  knowledge 
whether  or  not  descriptive  data  are  in  relational  triples. 

These  reasons  support  the  arginnent  for  storing  shared  data  as  relational 
triples  (or  their  equivalent)  or  in  a  relational  database  that  permits  multi¬ 
ple  values  and  permits  a  value  to  be  a  string  (e.g.,  "This  is  a  string.")  or  a 
list/tuple  (e.g.,  a  Lisp  or  Prolog  list  or  a  ROSIE  tuple).  (The  data  used  by 
fusion  inference  rules  do  not  require  strings  and  could  probably  be  expressed 
without  lists  or  tuples  if  necessary. )  To  test  this  approach,  we  will  use  as 
ex2UDples  the  events  involved  in  an  antisubmarine  warfare  mission  and  an  anti 
surface  warfare  mission. 

In  reference  2,  the  concepts  of  an  "actual"  event  and  a  "virtual"  event 
were  Introduced.  The  term  "event"  is  used  in  a  general  sense  to  refer  to  an 
activity,  situation,  or  static  state.  An  "actual"  event  is  one  that  is  re¬ 
ported  either  to  have  occurred  or  possibly  to  have  occurred,  and  a  "virtual" 
event  is  one  that  has  not  occurred  (at  the  time  of  the  report)  and  that  may  be 
a  planned  or  ordered  activ’  ty  or  a  prediction  or  expectation  of  an  event.  The 
concept  of  a  "supporting"  event  (such  as  the  launching  of  aircraft  in  support 
of  an  attack)  was  also  introduced  in  reference  2.  Since  then  we  have  found  it 
useful  to  include  the  concept  of  an  "ongoing"  event.  in  the  following  discus¬ 
sions,  the  prefix  $  will  indicate  an  actual  event,  the  prefix  V$  will  indicate 
a  virtual  event,  and  the  prefix  0$  will  indicate  an  ongoing  event. 

Much  of  the  message  traffic  concerns  plans.  Samples  appear  in  Appendix  A 
under  category  1  (failure  or  absence),  category  2  (cause  of  cessation,  failure 
or  plan  change),  category  5  (conditional  plans),  and  category  6  (other  mix¬ 
tures).  Consider,  for  example,  the  narrative  "SCHEDULED  1200  LAUNCH  TO  LOCATE 
AMD  ATTACK  DELTA."  Figure  3  gives  a  representation  of  the  planned  events, 
shown  there  as  virtual  events  in  a  "node-arc"  depiction.  Several  "isa"  state¬ 
ments  involving  the  events  are  not  shown,  and  other  data  from  the  message  and 
from  earlier  messages  would  add  other  relations  to  the  representation.  Later 
message  narrative  might  never  state  that  a  search  was  conducted,  but  a  number 
of  events  such  as  buoy  dropping  and  sonar  dipping  would  clearly  imply  a 
search.  By  making  these  individual  searching  activities  subsidiary  events  of 
the  more  comprehensive  event  labeled  $SURVEIL/SEARCH,  we  will  later  be  able  to 
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Figure  3.  Repr-,sentation  of  'SCHEDULED  1200  LAUNCH  TO  LOCATE  AND  ATTACK  DELTA.” 
The  ‘s”  label  on  arcs  represents  support. 


6 


determine  that  these  events  fulfilled  the  virtual  event  V$SURVEZL/SEARCH.  An 
option  is  to  exclude  tho  V$LOCATEfiji:D  event  in  the  plan  representation,  since 
(as  discussed  later)  it  could  be  inf^trred  if  needed*  Another  option  is  to 
create  the  virtual  event  which  has  the  other  virtual  evants  as  sub¬ 

sidiary  events.  This  might  be  esthetically  pleasing  and  could  sometimes  be 
useful,  but  would  add  a  level  of  complexity. 

Most  subsystems  (NLP,  fusion,  planning,  etc.)  will  have  a  method  of 
numbering  successive  instantiations  of  tracks,  events,  contacts,  etc.  For 
example,  the  tracks  created  in  ROSIE  will  TRACK  #1,  TRACK  #2,  ....  Most 
other  systems  written  in  Lisp  represent  instantiations  with  a  single  Lisp 
"atom,"  e.g.,  SIGHTING 1 ,  SIGHTING2,  ....  We  are  assuming  in  our  sample  im¬ 
plementations  in  ROSIE  that  as  the  system  receives  data  from  different  sources 
it  renumbers  events,  reports,  etc.  One  exception  to  our  numbering  scheme  in 
ROSIE  will  be  the  numbering  of  contacts.  In  this  case  tbs  use  of  a  prefix  or 
suffix  or  other  indication  of  the  source  cam  be  used  to  avoid  duplicate  names. 

Figure  4  gives  an  example  concerning  the  inability  tc  monitor  buoys. 
Although  the  NLP  system  probably  would  give  the  helo  as  the  actor,  the  con¬ 
struction  of  the  representation  would  include  inferring  that  the  patrol  is  the 
actor s  and  the  helo  would  be  linked  in  the  manner  shown.  Figure  4  also  illus¬ 
trates  the  use  o£  a  Lisp  string  to  store  comments  available  to  the  user  but 
not  necessarily  to  inferencing  subsystems.  (2nery  and  inheritance  mechanisms/ 
rulesets  (discussed  later)  would  m<ike  it  easy  to  "see*  that  the  patrol  is  in  a 
helicopter. 

Figure  5  shows  the  '.-.ey  events  and  relationships  in  an  antisubmarine  war¬ 
fare  mission.  Examples  or  the  kinds  of  relationships  appearing  in  the  query 
database  for  this  mission  are  shown  in  a  ROSIE  typescript  in  Appendix  B. 
Figure  6  gives  the  representation  for  an  entisurface  warfare  mission. 

A  narrative  report  of  a  planned  or  actual  aircraft  launch  usually  lists 
several  aircraft,  e.g.,  "SIX  A-7,  ONE  A-6,  ONE  EA-6B."  Different  aircraft 
launched  in  the  same  series  have  different  roles  and  cycle  times.  The  roles 
may  be  ASW,  surveillance,  strike,  plane  guard  (ready  for  rescue  operations), 
screen,  airborne  early  warning,  etc.  The  report  of  a  planned  launch  of  sever¬ 
al  aircraft  is  better  represented  by  a  virtual  event  whose  "launched"  is  a 
"plat-group"  (with  its  composition  specified  so  far  as  kno%m)  than  by  an  indi¬ 
vidual  virtual  event  for  each  p].ane.  Narrative  reports  of  an  ASW  or  strike 
mission,  however,  often  involve  a  single  aircraft.  Note  in  figures  5  and  6 
that  the  S-3A  and  E-2  each  is  represented  by  a  specific  aircraft  which  is  a 
"part"  of  a  launched  plat-group. 

Other  examples  of  platform  groups  can  be  seen  in  figure  6.  While  the 
original  plan  called  for  a  task  group  to  locate  and  strike  a  group  of  specific 
platforms,  individual  matches  were  not  then  feasible.  Note  that  a  conversion 
from  the  narrative  (in  the  caption  of  figure  6)  to  the  representation  requires 
creating  plat-group5  by  removing  the  ship  Barsuk  from  plat-group2. 

The  asserted  actor  of  an  event  usually  will  be  a  platform  or  a  platform 
group,  but  when  a  better  defined  actor  (e.g.,  the  patrol  of  an  ASW  mission)  is 
known,  using  it  as  the  actor  generally  will  give  a  more  accurate  representa¬ 
tion. 


Figure  4.  Representation  of  “helo  dropped  buoys  but  was  unable  to  monitor”  and  some  of  the  back¬ 
ground  data.  The  relation  “comment”  would  be  accessible  to  query  and  history  subsystems  but  not 
necessarily  *.o  inferencing  subsystems. 
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Figure  5.  Interrelation  of  events  and  other  concepts  for  an  antisubmarine-warfare  mission. 
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CONTROLLER 


Figure  6.  The  “new”  information  shown  is  taken  from  a  message  giving  position  data  on  Barsuk  and 
the  narrative:  “Intention  is  to  have  Pegasus  maintain  position  commencing  2330T,  to  take  out  Barsuk 
on  signal  from  AS  when  hostilities  commence.  Attack  acft  from  Constellation  2330T  launch  will  be  used 
to  strike  other  hostile  surface  units,  if  located,  upon  commencement  hostilities.  Currently  conducting 
search  with  E-2.”  (a)  Key  events  and  relations,  (b)  Details  of  the  three  platform  groups:  TG  30.2, 

TU  30.1.1,  and  plat-group5. 


Figure  6B.  DeUils  of  the  three  platform  groups:  TG  30.2,  TU  30.1.1,  and  plat-group5. 
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The  representation  of  an  ASW  nlaslon  shown  in  figure  5  disregards  any 
earlier  reports  providing  virtual  event  records  which  predict  the  actual 
events,  with  the  exception  of  V$ATTAac6.  V$ATTACK6  can  be  considered  as  a 
plan  of  $ATTACK4  and  $ATTACK5  and  is  fulfilled  if  tne  intended  victim  is  out 
of  action  as  a  result.  It  is  also  fulfilled,  for  practical  purposes,  when  the 
planned  attacks  are  made  but  are  unsuccessful  and  the  mission  ends.  Similarly 
in  figure  6(a),  V$ATTACX1  will  be  fulfilled  when  every  platform  which  is  a 
part  of  plat-group2  is  out  cf  action.  If  we  were  to  continue  this  particular 
scenario  we  would  have  several  attacks  per  victim  platform,  and  V$ATTACK1 
would  be  fulfilled  at  the  termination  of  the  mission  whether  or  not  success¬ 
ful. 

Other  comments  about  figures  5  and  6  are  listed  below. 

•  The  following  kinds  of  assertions  are  not  shown  but  will  be  in  the 
database.  (The  syntax  will  vary  from  system  to  system,  and  the  rela¬ 
tion  names  are  arbitrary.) 

-  $ [event-name]  is  an  event. 

-  V$ (event-name ]  is  a  virtual-event. 

-  0$ [event-name]  is  an  ongoing-event. 

-  V$ATTAaC6  is  a  V$ATTACK. 

-  patrons  is  a  patrol. 

-  $L0CATE4ID32  is  an  event  of  $ASW-MISSI0N3. 

(Some  events,  e.g.,  $SURVEIL/SEARCH,  in  turn  have  subsidiary 
events . ) 

-  $BU0Y-DR0P18  is  an  event  of  $SURVEII,/SEARCH9. 

•  Support  relationships  such  as  the  following  usually  can  be  inferred 
froru  •■hfc  event  descriptions  in  the  database  but  are  better  inferred 
earlier  and  entered  into  the  dataJaase.  (Support  is  represented  by  "s" 
in  the  figures.) 

-  $ACFT-LAUNCH  is  a  support  of  TRANSIT-TO-OPAREA. 

-  $TRANSIT-TO-OPAREA  is  a  support  of  $0NSTATI0N. 

-  $TRANSIT-TO-BASE  is  a  support  of  RETURNED-TO-BASE. 

-  SSURVEIL/SEARCH  is  a  support  of  SLCXTATE&ID. 

-  $LOCATEfiID  is  a  support  of  $ATTACK. 

•  The  occurrence  of  some  events  not  in  the  original  data  can  be  inferred 
from  other  events. 

-  yONSTA  =>  TRANSIT-TO-OPAREA  =•>  (for  aircraft)  $ACFT-LAUNCH 

-  $RETURNED-TO-BASE  =>  $TRANSIT-TO-BASE 

-  $ATTACK  =>  $L0CATE«ID 

The  information  shown  in  figures  5  and  6  (and  many  of  the  implied  rela¬ 
tionships  described  above)  are  stored  in  database  as  an  unordered  set  of  rela¬ 
tional  triples.  Examples  of  the  generic  form  of  these  for  the  ASW  mission  are 
shown  in  table  1.  This  representation  is  generic  in  the  sense  that  the  basic 
elements  can  be  understood,  via  simple  (in  principle)  translation,  by  any  sub¬ 
system  or  cooperating  system. 
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Table  1  •  Gamrlc  representation  of  $ASW‘-MISSI0N3. 


NodeA/OBJECT 

RELATION/ATTRIBOTE 

NodeB/VALUE 

SASW-MISSI0M3 

ISA 

SASH-MISSION 

$ASH-MISSI0N3 

ISA 

EVENT 

$ASN-MISSI0M3 

ACTOR 

PATROL 15 

$AS1I-M1SSI0N3 

GOAL 

V$ATTACK6 

$V$ATTACX6 

VICTIM 

S0B-C0NTACT-SA3 

SUB-CaJTACT-SA3 

CLASS 

DELTA 

SUB-C0NTACT-SA3 

TRACK 

TRK59 

SoM  additional  inforaation  about  the  relations  is  often  needed  by  partic¬ 
ipating  systeois  or  their  user,  such  as  aultiple  values  aund  automatic  inheri¬ 
tance.  Additional  knowledge  often  needed  concerns  the  value  node;  e.g. ,  is  it 
numeric?  an  integer?  a  tuple  or  list?,  does  it  have  a  finite  set  or  restricted 
range  of  values?,  etc. 

Inheritance  mechanisms  vary  among  systems,  and  translation  for  the 
triples  concerned  will  be  more  difficult,  the  triples 

(CLASS  VARYAG  iCRlCA}  and  (TYPE  VAHYAG  DESTROYER) 
need  to  be  expressed  as 

(ISA  VARYAG  KYNDA)  and  (ISA  KY1«3A  DESTROYER) 

if  the  automatic  inheritance  mechanisms  of  some  systems  are  to  be  employed. 
Fortunately,  almost  all  relations  involving  inheritance  need  be  entered  into  a 
system  only  at  its  initialization,  and  the  problem  will  rarely  occur  with  tac¬ 
tical  event  descriptions.  Appendix  C  contains  examples  of  rulesets  used  in 
ROSIE  to  enedsle  inheritance  of  certain  features  eund  attributes.  Similar  rules 
can  be  implemented  in  STAMMER2,  although  the  current  version  enters  the  gener¬ 
ated  attribute  into  the  database  while  the  current  version  of  ROSIE  does  not. 
Inheritance  mechanisms  can  be  shared  by  fusion  and  question-answering 
processes . 

OSBR  IVTBRACTIOHS 

User-assisted  fusion  is  needed,  for  example,  when  the  conditions  of  a 
good  tactical  inference  rule  are  not  all  amenable  to  automatic  evaluation.  If 
all  but  an  untractable  condition  are  evaluated  true  (assuming  forward- 
chaining),  the  system  can  ask  the  user  if  that  condition  is  met,  e.g.,  if  a 
certain  formation  or  pattern  of  movements  (obvious  to  the  viewer  of  an  NTDS  or 
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radar  screen)  ha:i  occurred.  Also,  a  ruleset  can  be  activated  enabling  a  graph¬ 
ical  review  of  the  pertinent  information.  Appendix  D  shows  a  sample  implemen¬ 
tation  of  ROSIE  rulesets  enabling  interaction  with  the  user.  User-assisted 
fusion  probably  would  have  to  be  an  option  to  each  user.  As  geometry  comput¬ 
ing  capabilities  increase,  the  feature  would  be  needed  less. 

Automatic  computation  and  presentation  of  fused  data  could  theoretically 
be  varied  from  high-threat  warnings  alone  to  every  new  inference  plus  every 
shift  of  confidence  values  for  every  set  of  hypotheses  affected  by  each  new 
report.  For  the  Matter  situation,  the  significant  conclusions  could  be  identi¬ 
fied  and  only  these  presented,  but  there  remains  the  problem  that  real-time 
processing  may  not  be  aohievable  for  some  years.  For  example,  experiments 
(references  9  and  10)  with  computing  confidences  (using  Dempster-Shafer  meth¬ 
ods)  for  platform  identification  and  simple  contact  association  problems  have 
shown  that  the  computation  of  confidences  will  consimie  a  very  high  proportion 
of  the  total  processing  time.  The  approach  taXen  in  those  experiments  is  to 
perform  confidence  computations  only  %#hen  the  user  requests  them,  and  this 
•^uld  usually  be  for  a  single  contact  after  several  pieces  of  evidence  concern¬ 
ing  the  contact  are  available. 

While  efficiency  is  one  important  aspect  of  the  problem  of  what  to  auto¬ 
matically  present  a!vd  what  to  compute  only  upon  demand,  user  preference  is 
obviously  emother.  Every  user  should  be  informed  of  urgent  problems,  e.g., 
the  enemy  targeting  of  a  missile  on  ownship,  but  some  might  wish  to  tell  the 
system  what  kinds  of  information  to  present  and  then  interact  seidomly  while 
others  might  wish  to  examine  the  fused  data  primarily  on  a  query  basis.  It 
becomes  difficult  at  this  point  to  distinguish  clearly  between  question¬ 
answering  processes  and  fusion  processes,  and  it  appears  that  a  desirable  capa¬ 
bility  is  that  of  shifting  the  different  kinds  of  responsibility  from  one  to 
the  other  at  the  pleasure  of  the  user.  A  procedure  ruleset  such  as  (in  ROSIE 
syntax)  “Sumitarize  threats  to  platform"  can  respond  either  to  a  user  request 
or  a  routine  automated  call. 

Normally  a  natural  l^ulgvage  (NL)  interface  query  system  would  translate 
questions  into  structured  queries  in  the  DBMS  language  to  obtain  the  right 
answers.  As  suggested  above,  however,  much  of  the  procedural  knowledge  needed 
to  retrieve  information  from  the  database  can  be  used  for  more  than  one  func¬ 
tion,  e.g.,  the  same  process  might  be  used  in  answering  a  question,  in  provid¬ 
ing  a  routine  situation  assessment,  in  formulating  a  plan,  and  in  evaluating 
an  inference  rule  condition.  In  addition  to  translating  a  user's  natural 
language  question  into  a  database  query,  an  NL  interface  could  translate  more 
complex  requests  on  selected  subjects  into  the  high-level  language  of  the  ex¬ 
pert  system.  In  ROSIE,  for  example,  procedural  knowledge  would  be  implemented 
as  rulesets  and  the  question  might  be  translated  into  a  query  using  the  syntax 
of  the  pertinent  ruleset  headers.  Typical  available  rulesets  might  include 
the  generator  ruleset  "to  generate  opposing_ platform  with  equipx  within  rangeX 
of  plat"  or  the  predicate  ruleset  "to  decide  new-contact  is  unlike  earlier- 
plat."  (Rulesets,  in  turn,  can  call  on  others.)  The  question,  "Which  friend¬ 
ly  ships  are  within  missile  range  of  which  hostile  ships?"  could  be  translated 
into  the  ROSIE  retrieval  request  (actually,  its  parsed  equivalent): 

Fbr  each  platform  (friendly) 
whose  ID  is  friend 
and  %rhose  mediiat  is  surface. 
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for  each  Bleslle-type  (mel), 

for  each  opposing  platfora  (eneay)  with  asl  within 
{the  aax-range  of  asl)  of  friendly, 
display  friendly 
and  display  onemy. 

Note  that  the  call  on  the  "opposing  platform"  ruleset  activates  geometry  compu¬ 
tations  using  ship  positions,  so  this  process  is  not  data  retrieval  alone.  We 
have  not  concluded  that  translation  of  queries  into  an  expert  system's  high- 
level  language  is  a  practical  approach,  but  it  is  one  to  be  considered. 

Tailoring  the  system  to  a  particular  user  could  be  achieved  in  a  number 
of  ways,  one  being  to  use  flags  wtrloii  permit  certain  procedural  rulesets  to  be 
activated  under  certain  conditions.  The  flag  values  for  a  particular  user 
would  be  set  during  an  initial  interrogation  and  could  be  changed  by  that  user 
any  time. 


SOMNART 

^e  emphasis  in  this  task  has  been  on  the  fusion  of  tactical  data,  but 
fusion  processes  must  integrally  overlap  with  planning,  query,  and  historical 
recons tr'.’.ction /ana lyses  processes.  Many  different  kinds  of  knowledge  engineer- 
ing  approaches  are  being  applied  to  the  various  facets  of  C3  problems.  The 
data  structures  of  the  applicable  expert  systems  vary  greatly,  and,  in  gener- 
*1*  "talk"  asiong  these  systems  has  not  occurred.  The  two  prijit^ry  concerns 
addressed  in  this  report  are  the  following. 

e  TOie  cooperative  subsystems  of  a  total  C3  system  must  share  descriptive 
data.  Can  plans,  events  and  other  complex  concepts  be  represented  in 
a  "generic"  form  understandable  by  all  of  these  subsystems? 

-  Tactical  planning  systems  must  base  plans  on  assessments  tacti¬ 
cal  situation. 

-  Data  fusion  processes  must  have  knowledge  of  the  ownforce  plans 
being  carried  out  in  order  to  assess  the  situation. 

-  Reconstruction  and  post-analysis  systems  most  have  knowledge  of 
plans,  events,  and  the  fusion  system  conclusions. 

-  &iery  systems  —  and  each  above  subsystem  might  have  its  own  —  must 
be  able  to  answer  questions  about  the  plans  and  f\ised  data. 

•  Much  of  the  same  procedural  knowledge  is  needed  by  the  different  sub¬ 
systems.  How  can  they  efficiently  share  it? 

-  Question-answering  and  data  fusion  often  involve  the  same  reasoning 
and  computing  processes. 

-  One  user  may  wish  certain  information  to  be  automatically  presented 
while  another  may  wish  it  fused  and  presented  only  upon  request. 

The  approach  recommended  for  sharing  descriptive  data  is  to  use  two-node  rela¬ 
tional  assertions,  allowing  the  value  node  to  have  multiple  values.  Values 
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should  be  permitted  to  be  strings  or  lists/tuples,  primarily  for  use  by  the 
query  system.  Examples  of  antisubmarine  warfare  events  and  antisurface  war¬ 
fare  events  were  implemented  to  test  this  approach.  Representations  made  use 
of  three  kinds  of  events:  "virtual"  (planned/predicted),  "ongoing,"  and  "actu¬ 
al."  The  representation  of  events  having  multiple  actors  and/or  multiple 
objects  or  victims  made  uae  of  "platform  groups." 

Procedural  responsibilities  can  be  shifted  between  fusion  functions  and 
question-answering  functions  by  representing  the  sharable  processes  modularly, 
generally  as  distinct  rulesetn.  These  rulesets/m~dules  could  be  called  both 
by  the  fusion  functions  the  user  wishes  automatically  performed  and  by  a  query 
system  which  translates  questions  into  the  high-level  language  of  the  expert 
system. 

Other  issues  addressed  in  this  report  were  the  sharing  of  linguistic  know¬ 
ledge,  user-assisted  fusion,  and  the  subdivision  of  memory  for  efficient  rule 
evaluation. 
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APPEBDIX  A:  EXAMPLES  OF  MAARATIVE  CCHICXPTS 


1.  Failure  or  Absence 

PEGASUS  UNABLE  TO  ACQUIRE  BARSUK. 

E-2  UNABLE  TO  LINK  ... 

UNABLE  TO  CONTACT  AAWC  ON  VIRGINIA 

UNABLE  TO  ESTABLISH  COMM  WITH  SFC  UNITS  ON  ANY  CKTS. 

HELD  DROPPED  BUOYS  BOT  WAS  UNABLE  TO  MONITOR. 

NIL  WEAPONS  FIRED. 

NO  UNUSUAL  AIR  ACTIVITY  REPORTED 
MY  PRESENCE  UNKNOWN  TO  ENEMY. 

SUSTAINED  NO  DAMAGE  FROM  KYNDA. 

THE  REMAINING  SWIMMER  PAIRS  SUCCESSFULLY  PLACED  ...  WITHOUT 
BEING  DETECTED. 

DIFAR  BUOYS  WERE  DEPLOYED  BOT  WERE  UNABLE  TO  FIX  SUB. 

REGRET  ADDITIONAL  VP  ASSETS  UNAVAILABLE  TO  ASSIST  IN  PROSECUTION. 

CREW  ALSO  CONDUCTED  RADAR,  ESM  AND  FLIR  SEARCH  WITHOUT  SUCCESS 

2.  Cause  of  Osaation,  Failure,  or  Plan  Change 
LOST  CONTACT  AS  SUB  WENT  BELOW  LAYER. 

HEAVY  SMOKE  PRECLUDES  FURTHER  INTERPRETATION.  . 

CONTACT  WAS  LOST  BEFORE  TARGET  COULD  BE  LOCALIZED. 

SHIPS  SONAR  OOC  AS  RESULT  OF  LIMPIT  MINE  EXPLOSIONS. 

...  BUT  DUE  TO  INTERMITTENT  COVERS)  VOICE  WAS  UNABLE  TO  RAISE  CONTROLLERS. 

...  BUT  WAS  INTERCEPTED  BY  ORANGE  AIRCRAFT  AND  FORCED  TO  DISCONTINUE  SEARCH. 

BECAUSE  OF  TIME  DELAY  AND  DISTANCE  WHICH  WILL  BE  NECESSARY  TO  TRANSIT  TO  PHASE 
IV  START  PTS,  UNITS  WILL  BE  UNAVAILABLE  TO  REFUEL,  REARM,  AND  ARRIVE  AT  START 
PTS  ON  TIME.  IT  MAY  BE  NECESSARY  TO  CANCEL  REARM. 

FANNING  AND  MILLER  PURSUED  KOBCHIK  UNTIL  WITHIN  GUN  RNG, 

LATE  ONSTA  DUE  ACFT  MALFUNCTIONS 


A-1 


TASS  ONZTS  HOT  TRAILING  ARRAYS  DOE  HIGH  SPEED  OPS  AND  SORPACE  ENGAGEMENTS 

UNABLE  TO  PROSECUTE  FURTHER  DUE  TO  NEW  TASKING  BY  COMDESRCBI  23. 

REMAINED  ONSTA  FOR  EXTPA  1  15  HRS  DUE  TO  LATE  ARRIVAL  OF  RELIEF. 

...  HOWEVER  SHORT  ONSTA  TIME  REMAINING  PRECLUDED  FURTOHl  TARGET  PROSECUTION. 

HEAVY  ELECTRONIC  EMISSICMIS  NOTH)  EMANATING  FROM  AGI  ...  TOOK  AGI  UNDER  FIRE 
...  AIL  ELECTRONIC  EMISSIONS  FROM  AGI  CEASED 

MILLER  TOOK  UNIDB1T  CONTACT  WHICH  FAILED  TO  RESPOND  TO  CHALLENGE  UNDER  FIRE. 
SHIP  HAY  HAVE  BEEN  WAINWRIGHT. 

TRACKED  SUB  FOR  1  HR  30  MIN  THEN  LOST  CONTMTT. 

SEARCH  EFFORT  HILL  CONTINUE  ...  UNTIL  ALL  ORANGE  UNITS  LOCATED. 

3.  Tiag 

3a.  Order 

VISUAL  ID  ON  ADM  GOLOVKO,  ATTACKED  SUCCESSFULLY  ON  ACM  GOLOVKO  WITH  GUNS. 
BROKE  ENGAGEhENT.  RETURNED  TO  SCREEN.  ADM  GOLOVKO  CLEARING  ... 

GREEN  FLARES  SIGHTED  SHORTLY  AFTER  VISUAL  ON  PERISCOPE 

P  10  COMMENCED  ATTACK  RUN  BY  FIPLNG  TWO  TORPEDOES  FOLLOWED  BY  TWO  MISSILES. 

ESTABLISHED  COMMS  WITH  USS  BRONSTEIN  PRIOR  TO  ARRIVAL  ONSTA  2300Z 

PROCEEDED  TO  LAY  AN  INVERTED  ACTIVE  CHEVRON  BARRIER  AND  IMMEDIATELY  GAINED 
CONTACT 

3b.  Interval 

HELD  CONTACT  FOR  7  MIN. 

HErJ>  riRM  CONTACT  FOR  25  MIN.  BRIEF  CONTACT  HELD  ON  PCSS  SUB. 

PERISCOPE  REMAINH}  VISUAL  FOR  APPROX  1  5  MIN  AT  SNORKEL  DEPTH 

PROVIDED  SURFACE  PLOT  INFO  AND  COMM  RELAY  FOR  TASS  UNITS  THROUGHOUT  PERIOD 

OBTAINED  MODE  IV  CHECK  AND  LINK  CHECK  ENROUTE  BASE 

THIS  INTERCEPT  OCCURRED  WITHIN  THE  TIME  FRAME  DURING  WHICH  A  MISSING  RA-5C 
WOULD  HAVE  BEO)  IN  THE  VICINITY  OF  PURPLE. 

3c .  Ongoing 

CONTINUING  EFFORT  TO  LOCATE/IDENTIFY  ... 


A-2 


MILLER  HAS  HAD  CONTINUOUS  CC»ITACT  WITH  SKAMPI 


CURRENTLY  CONDUCTING  SEARCH  WITH  E-2. 

AS  OF  202300T,  OTIE  E-2  ACFT  UNDER  AW  CONTROL  IS  PROVIDING  SURFACE  SURVEILLANCE 
DATA  AS  FEASIBLE. 

PEGASUS  CURRENTLY  ENROUTE  TO  ATTACK  ZHEVNY  WITH  GUN. 

E-2  ACFT  PRESENTLY  ASSIGKO  SO;.-  'DVIDING  UPDATE  ON  ALL  TRACKS. 

ACFT  RETURNING  TO  CONSTELLATION  iCi'  2030  RECOVERY. 

CONTINUING  TO  SEARCH  AREA. 

i,tiALL  MISSILE  CRAFT  CONTINUE  HARRASSMENT  OF  MERCHANT  SHIPS. 

CONTINUED  SEARCH  FOR  AGI  PELENG  AT  LAST  KNOWN  POSIT. 

...  AND  CREW  CONTINUED  TO  TRACK. 

FORCE  HAS  SUSTAINED  LIMITED  DAMAGE,  BUT  IS  CONTINUING  ENROUTE  PT  WINFIELD. 

AT  1716Z  RESUMED  PLANE  GUARD. 

COMMENCING  2330T  CONTINUOUSLY  MONITOR  STATION  RELATIVE  TO  BARSUK  FROM  WHICH 
YOU  CAN  LAUNCH  IMMEDIATE  MISSILE  ATTACK. 

INTEND  CONTINUE  EFFORT  TO  LOCATE  REMAINING  KYNDA 

INTENTIONS:  CONTINUE  TRANSIT  LOCATING  AND  ENGAGING  ORANGE  UNITS. 

3d.  Other 

...TO  UPDATE  POSITION  ON  ORANGE  UNITS  AT  LEAST  EVERY  SIX  HOURS. 

SUBSEQUENTLY  FORCE  SUBJECTED  TO  INTERMITTENT  ATTACK  DY  AIR,  SURFACE  AND 
SUBSURFACE  UNITS  THROUGHOUT  THE  DAY. 

INTEND  LAUNCH  ADDITIONAL  ACFT  AT  221130T  TO  . . .  .  NO  ACFT  AVAIL  PRIOR  THAT 

TIME. 

4.  Logical  and  Fuzzy  ^antifiers 
10  ASROC  REMAINING. 

FIRED  2  OR  3  BIRDS  EACH  TARGET. 

ALL  ORANGE  SURFACE  COMBATANTS  STRUCK  ONCE  SINCE  221115T;  BARSUK  STRUCK  TWICE. 

ALL  ORANGE  SURFACE  UNITS  HAVE  NOW  BEEN  STRUCK  AT  LEAST  ONCE  AND  SEVERAL 
REPEATEDLY  WITH  CONSTELLATION  ACFT. 
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CONTACT  APPEARS  TO  BE  ON  PATROL  SURVEILLANCE  STATION 


ONLY  SSM  INTERCEPT  RECEIVED  ON  PELENG  SINCE  171624Z1. 

IDENTITY  OF  BARSUK  AND  KOBCHIK  MAY  BE  REVERSED. 

HKT.n  REPORTED  FF  TYPE  WITH  HULL  NUMBERS  WITH  LAST  NUMBER  INDISTINGUISHABLE. 

RELIABLE  INTELLIGENCE  POSITIONS  TWO  ORANGE  SUBMARINES  TO  WEST  OF  BLUE 
ANCHORAGES. 

IN  A  POSSIBLE  RELATED  REPORT,  A  RELIABLE  SOURCE  ON  PURPLE  DISCOVERED  WHAT  HE 
BELIEVES  TO  BE  A  RECENT  AIRCRAFT  WRECKAGE  SCATTERED  OVER  A  LARGE  AREA  OF  THE 
WESTERN  PGRTION  OF  THE  ISLAND  NATION,  ONE  OF  THE  LARGER  PIECES  FOUND  HAD  BLUE 
MARKINGS. 

5.  Conditional  Plans 

WILL  PICK  UP  AMPLIFIER  VIA  MY  HELO  IF  AVAIL. 

ATTACK  ACFT  FROM  CONSTELLATION  2330T  LAUNCH  WILL  BE  USED  TO  STRIKE  OTHER 
ORANGE  SURFACE  UNITS,  IF  LOCATED,  UPON  COMMENCEMENT  HOSTILITIES. 

INTEND  LAUNCH  ALERT  ACFT’  FOR  STRIKE  AGAINST  ADM  GOLOVKO  WHEN  LOCATED. 

PHOTOGRAPH  AND  ID  IF  SURFACING  OCCURS. 

IF  DESIRE  REFUEL  SURFACE  COMBATANTS  RCMD  HAVE  MLSP  GROUP  CLOSE  ASTERN  OF  CV 
GROUP  AND  BREAK  OFF  COMBATANTS  TO  REFUEL  INDIVIDUALLY. 

6.  Other  mixtures 

ATTACK  WILL  BE  LAUNCHED  ON  SIGNAL  FROM  AS  UPON  COMMENCEMENT  HOSTILITIES 
SOMETIME  AFTER  2359T. 

TASS  SHIPS  ARE  WIDELY  DISTRIBUTED  AT  THIS  TIME  ... 

ALBKT  A-6,  A-7  TO  AUGMENT  AS  NECESSARY  FOR  MAJOR  STRIKES  AGAINST  ORANGE  UNITS 
PRESENTIKu  IMMEDIATE  THREAT  TO  FC»CE. 

ANTICIPATE  APPROX  60  ACFT  ARE  AVAIL  FOR  IMPENDING  OPERATIONS. 

BELIEVE  I  HAVE  RUN  ACROSS  ALL  ORANGE  FORCES. 

WILL  STRIKE  KOBCHIK  WITH  AIRBORNE  ACFT  WHEN  HOSTILITIES  COMMENCE. 

PELENG  REMAINING  IN  GENERAL  VICINITY  NIMITZ  BUT  NOT  IN  CONTINUOUS  CLOSE 
SURVEILLANCE/SHADOWING  ROLE.  NO  UNUSUAL  ACTIVITY. 

ACFT  DROPPED  DIFAR  BUT  ADP  HAD  FAILED.  UNSUCCESSFULLY  ATTEMPTED  TO  VECTOR 
HELO  TO  SINKER  POSITION,  WHICH  WAS  5NM  225T  FROM  CV 

CONTINUED  TO  DIP  AND  CONDUCT  MAD  SWEEPS  WITHOUT  CONTACT.  RETURNED  TO  PLANE 
GUERD  AT  0130Z. 
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BRONSTEIN  LATER  GAINED  TASS  CONTACT  AND  USING  DIFAR  BEARING  INFO  GENERATED  BY 
SLVG  7C3,  DEVELOPED  AN  AOP  WITH  CUS/SPD. 


LOST  ACTIVE  SONAR  CONTACT  PRIOR  TO  OBTAINING  FIRING  SOLUTION.  NO  JOY 
ATTEMPT  TO  REGAIN  CONTACT  ANY  SENSOR. 

Acronyng 

AAWC  "  anti-air  warfare  cxanmander 

ADP  —  automatic  data  processing 

AOP  —  area  of  position /probability 

AS  —  call  sign  of  coomander 

CRTS  —  circuits 

OOC  —  out  of  conunission 

SFC  --  surface 

SLVG  703  —  a  patrol's  call  sign 
SUHC  --  surface  warfare  coordinator 
VP  —  US  patrol  squadron 

Soviet  Shipp 

ADMIRAL  GOLOVKO 
BARS UK 
KOBCHIK 

KYNDA  <a  class  name) 

PEGASUS 

PELENG 

SKAMPl  (a  fictitious  sub) 
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APPENDIX  B,  EXAMPLES  OF  DATA  IN  QUERY-ONLY  MEMORY 


TM 

I  Rosie  Version  1.3  ll-Jul-83  07:29:13 

<3>  load  cc-querybase. 

<4>  display  the  crew  of  patrol  115. 

<4,  TC-LCDR  BURNS,  PC-LT  PULLER,  DBO-LT  MORGAN> 

<5>  describe  pattern  *8. 

I  PATTERN  «8  ] 

PATTERN  *8  la  a  pattern. 

PATTERN  #8  is  a  pattern  of  $BUOY-DROP  #8. 

BARRIER  is  a  type  Cf  PATTERN  18. 

6 OPT  is  a  depth  of  PATTERN  *8. 

3HR  is  a  duration  of  PATTERN  #8. 

22 5T  is  an  orientation  of  PATTERN  18. 

11  is  a  max-row-length  of  PATTERN  #8. 

4NM  is  a  buoy-distance  of  PATTERN  #8. 

11  is  a  buoy-count  of  PATTERN  #8. 

1  is  a  row-count  of  PATTERN  #8. 

<6>  display  every  expendable  of  $ASW-mi88ion  #3. 

<25,  SSQ-41> 

<1  NK-46> 

<2,  MK-82> 

<7>  for  each  event  (e) , 

if  there  is  a  comment  (c)  on  e, 
display  e  and  display  c. 

$BUOY-DROP  #8 
"ahead  of  Brumby* 

$BUOY-MONITOR  #8 

"held  weak  contact  7  min* 

$MALFUNCTION  12 
"ATR  tube" 

<8>  for  each  report  (r), 

if  there  is  a  comment  (c)  on  r, 
display  r  and  display  c. 

REPORT  #810 

"maneuvering,  changing  depth" 

<9>  logout. 
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APPENDIX  C.  RULESETS  FOR  INHERITANCE 
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1:  CC-INHERIT  Created  7-Jul-83  12:37:06,  edit  by  DILLARD  :J 

To  generate  medium  of  platform: 

Ill  If  (there  is  a  type  (x)  of  the  platform 
or  there  is  a  model  (x)  of  the  platform) 
and  there  is  a  medium  (m)  of  x, 
produce  m. 

End. 


To  generate  type  of  platform: 

[1]  If  (there  is  a  class  (x)  of  the  platform 
or  there  is  a  model  (x)  of  the  platform) 
and  there  is  a  type  (t)  of  x, 
produce  t. 

End. 


To  generate  ID  of  platform: 

(1]  If  (there  is  a  class  (x)  of  the  platform 
or  there  is  a  model  (x)  of  the  platform) 
and  there  is  an  id  (f)  of  x, 
produce  f. 

(21  If  there  is  a  type  (t)  of  the  platform 
and  t  >  AGI, 
produce  hostile. 

End. 


To  generate  flag  of  platform: 

11]  If  (there  is  a  class  (x)  of  the  platform 
or  there  is  a  model  (x)  of  the  platform) 
and  there  is  a  flag  (f)  of  x, 

produce  f. 

12]  If  there  is  a  type  (t)  of  the  platform 
and  t  AGI, 

produce  OR. 

End. 
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To  generate  nation  of  platformt 
Private  phlag. 

(1]  If  there  la  a  flag  (f)  of  the  platform, 

let  the  phlag  be  f, 

otherwise, 

return, 

(21  If  the  phlag  ■  US, 
produce  OS. 

[3]  If  the  phlag  ■  UR, 
produce  USSR, 

(41  If  the  phlag  «  UK, 
produce  United  Kingdom, 

[5]  If  the  phlag  <■  JA, 
produce  Japan. 

(61  If  the  phlag  •  IR, 
produce  Iran. 

(71  If  the  phlag  ■  CU, 
produce  Cuba, 

18]  If  the  phlag  «  CH, 
produce  China. 

[9]  If  the  phlag  <■  CA, 
produce  Canada. 

[10]  Produce  the  phlag. 

End, 


To  generate  propulsion  of  sub: 

[1]  If  there  is  a  class  (c)  of  the  sub 
and  there  is  a  propulsion  (p)  of  c, 
produce  p. 

End, 
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To  decide  plat  is  a  ahipx 
Private  ned. 

Ill  If  the  plat  ia  a  platform 

and  there  la  a  medium  (m)  of  the  plat, 

let  the  med  be  m, 

otherwise, 

conclude  false. 

12]  If  the  med  ■  surface 
or  the  med  ■  subsurface 
or  the  med  ■  amphibious, 
conclude  true. 

(3]  If  the  med  •  air 
or  the  med  >  land-surface, 
conclude  false. 

End. 


To  generate  ship: 

(1]  For  each  platform 
which  is  a  ship, 
produce  that  platform. 

End. 


To  decide  plat  is  an  aircraft: 

Private  med. 

(11  If  the  plat  is  a  platform 

and  there  is  a  medium  (m)  of  the  plat, 

let  the  med  be  m, 

otherwise, 

conclude  false. 

[2]  If  the  med  *  air, 
conclude  true. 

[3]  If  the  med  ■  surface 
or  the  med  >  subsurface 
or  the  med  «  amphibious 
or  the  med  land-surface, 
conclude  false. 

End. 
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To  gonorat*  aircraft t 


111  For  each  platform 
which  Is  an  alrcraftr 
produce  that  platform. 

End, 


To  decide  system  Is  an  equipment  of  plat: 

(1]  If  (there  Is  a  class  (x)  of  the  plat 
or  there  Is  a  model  (x)  of  the  plat) 
and  the  system  is  an  equipment  of  x, 
conclude  true. 

(21  Conclude  false. 

End. 


To  genera  ;<  max-speed  of  plat: 

Private  pi at- type. 

(11  If  (there  is  a  class  (x)  of  the  plat 
or  there  is  a  model  (x)  of  the  plat) 
and  there  is  a  max-speed  (ms)  of  x, 
produce  ms. 

(2]  If  there  is  a  medium  (m)  of  the  plat 
and  m  ■  air, 

if  there  is  a  type  (t)  of  the  plat 

and  t  ■  helicopter, 

produce  ISO, 

otherwise, 

produce  1200. 

(31  If  there  is  no  type  of  the  platform, 
produce  40, 

otherwise  let  the  plat-type  be  the  type  of  the  plat. 

(4)  If  the  plat-type  ■  fast-attack/patrol -craft, 
produce  45. 

(51  if  (the  plat-type  ■  carrier 
or  the  plat-type  »  cruiser 
or  the  plat-type  «  destroyer), 
produce  3  5. 

(61  Produce  30. 

End. 


C-4 


To  generate  time  of  aventt 

(11  If  there  la  a  report  (r) 
such  that  (r  is  a  data-report  of  the  event 
and  there  is  a  time  (t)  of  r) , 
produce  t. 

End. 


To  decide  thing  is  a  component  of  group: 

(11  If  the  thing  is  a  part  of  the  group, 
conclude  true. 

(21  For  each  part  (p)  of  the  group, 
if  the  thing  is  a  part  of  p 
or  (there  is  a  part  (pp)  of  p 
such  that  the  thing  is  a  part  of  pp) , 
conclude  true. 

(31  Conclude  false. 

End. 


To  generate  component  of  group; 

(11  For  each  part  (p)  of  the  group, 
produce  p 

and  for  each  part  (pp)  of  p, 
produce  pp 

and  for  each  part  (ppp)  of  pp, 
produce  ppp. 

End. 


To  generate  actor  of  eubevent: 

(11  If  there  is  a  type  (t)  of  the  subevent 
and  (t  ■  malfunction 
or  t  »  aircraft-launch 
or  t  »  change-op-control) , 
return. 

(21  If  there  is  an  event  (e)  such  that 
the  subevent  is  an  event  of  e, 
produce  the  actor  of  e. 

End. 
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APPENDIX  D.  RULESETS  FOR  USER-ASSISTED  FUSION 


(:  CC-USER-INPUT  Created  l-Jun-e3  13t08t28,  edit  by  DILLARD  :I 
To  generate  user-input  on  subject  for  argument: 

Private  answer. 

11]  Send  (return, 

"Please  type  y,  n,  x  (for  Don't  know)  or  ?  (for  Give  more  data).", 
return). 

12]  Read  for  seconds  (1  line  (bind  response)) 
and  (if  response  ■  "? 

m 

9 

go  tell.more  about  (the  subject)  for  the  argument 
and  send  (return, 

"Please  type  y,  n,  or  x.", 
return) 

and  read  for  240  seconds  (1  line  (bind  response))) 
and  let  the  answer  be  the  name  (response). 

13]  If  the  answer  *'*  y 
and  the  answer  'i 
and  the  answer  n 
and  the  answer  “■  N 
and  the  answer  % 
and  the  answer  *'*  X, 
send  (return, 

"Didn't  catch  that  answer.  Type  y,  n,  x,  or  ?.",  return) 
and  read  for  240  seconds  (1  line  (bind  response)) 

and  (if  response  >  "? 

• 

9 

go  tell.more  about  (the  subject)  for  the  argument 
and  send  (return, 

"Please  type  y,  n,  or  x.", 
return) 

and  read  for  240  seconds  (1  line  (bind  response))) 
and  produce  the  name  (response). 

(4]  Pr'^duce  the  answer. 

End. 


To  tell.more  about  subject  for  argument: 

(1)  If  the  subject  •  drift-ice-avoidance 
or  the  subject  «  neutral-coast-hugging, 
describe. track  of  the  argument. 

End. 
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To  decide  report  does  not^show  drift- ice-avoidance: 

Private  answer. 

[11  If  there  is  a  course-change-cause  (C3)  of  (the  report) 
such  that  c3  >  ice-avoidance, 
conclude  false. 

[21  If  there  is  a  latitude  (let)  of  the  report 
and  lat  <  60 
and  lat  >  -60, 
conclude  true. 

[31  If  the  user-flag  >  interaction, 
send  (return, 

"Is  it  likely  that  ",  the  report,  "  shows  a  change  in  course  ", 
"because  of  drift-ice?",  return) 

and  let  the  answer  be  the  user-input  on  drlft-lce-avoidance 
for  the  report, 
otherwise, 
conclude  true. 

(41  If  the  answer  «  N 
or  the  answer  «  X, 
conclude  true. 

(51  If  the  answer  ■  Y, 

assert  ice-avoidance  is  a  course-change-cause  of  the  report 
and  conclude  false. 

(61  conclude  true. 

End. 


To  describe.. track  of  xreport: 

Private  xtlme. 

(11  Let  the  xtiine  be  the  time  of  the  xreport. 

(21  If  there  is  a  track  (tr) 

such  that  the  xreport  is  a  report  in  tr, 

send  (return,  trl 

and  (if  there  is  a  platform  (plat)  of  tr, 
send  {■  Platform:  ",  plat,  return)) 
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and  for  each  report  (r)  in  tt, 
if  the  time  of  r  <-  the  xtiaef 
tend  (t,  "  Timet  ",  the  time  of  r) 
and  (if  there  ia  a  latitude  (lat)  of  r, 

send  (•  Lat:  ",  lat,  •  Lon:  ",  the  longitude  of  rl) 
and  (if  there  ia  a  courae  (c)  of  r, 
aend  C  Course:  ",  c}) 
and  aend  (return). 

Bnd. 


To  decide  report  doea  show  neutral-coast~hugging: 

Private  answer. 

(11  If  there  is  a  characteristic  (c)  of  (the  report) 
such  that  c  *  neutral-'coast-hugging, 
conclude  true. 

(2)  If  region  is  far  from  land, 
conclude  false. 

(3)  If  the  user-flag  •  interaction, 
send  (return, 

"Does  the  contact  appear  to  be  hugging  the  coast  line  of  a 

neutral  country?*, 

return) 

and  let  the  answer  be  the  user- input 

on  neutral-coast-hugging  for  the  report, 
otherwise, 
conclude  false. 

(41  If  the  answer  ■  N 
or  the  answer  -  X, 
conclude  false. 

(51  If  the  answer  •  Y, 

assert  neutral-coast-hugging  is  a  characteristic  of  the  report 
and  conclude  true. 


(61  Conclude  false 


